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SYSTEM AND METHOD FOR AUTOMATED FINANCIAL PROJECT 

MANAGEMENT 

FIELD OF THE INVENTION 

The present invention is related to and claims priority to U.S. 
5 Provisional Patent Application No. 60/163,506 entitled AUTOMATED 
FINANCIAL PROJECT MANAGEMENT SYSTEM, filed November 4, 1999, 
the contents of which are incorporated herein by reference. 

BACKGROUND OF THE INVENTION 

Project management, especially in the area of corporate real estate 

1 0 project management, is traditionally a process which is driven by paper forms and 
documents. These paper documents include for example, purchase orders, work 
orders, contracts. Requests for Assistance (RFA), Requests for Proposals (RFPs), 
commitments, bids, invoices, messages (generic correspondence), meeting 
announcements and minutes, project close outs, complete punch lists, project 

15 evaluations, and departmental statistics. 

The processing of all of these various documents is very labor 
intensive, error prone and subjects the proposed projects to needless delays. For 
example, if the manager in charge of approving commitments is on a business trip 
for two weeks, a commitment requiring his or her signature might be delayed for 
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an additional six weeks, which in turn delays another vendor's initiation of work 
and so on. 

Furthermore, an increase in the number of requests for new 
construction or engineering projects increases the volume of documents that are 
processed by the project administration group and the accounting operations 
group. This in turn requires an increase in processing capacity through an 
increase in staff levels or overtime. Conversely, a decrease in volume of requests 
lowers the productivity of the groups, as the staff levels are maintained to support 
the processing at the peak operations volume. 

SUMMARY OF THE INVENTION 

The present invention was originally designed to automate the 
project management process for the Corporate Real Estate and Facilities 
Department of the assignee of the present invention. Although originally 
designed for this type of real estate and facilities department, it is readily seen 
that the project management method and system of the present invention has wide 
applicability to most types of project management. 

The system is a collection of process and business objects that 
provide project management tools to support construction, renovations, 
maintenance and other projects. One primary function of the system is to 
automate the creation, processing and approval cycles of the numerous 
documents involved with each project. The system and method of the present 
invention provides automation to support the following business processes. 

Strategic Space Planning. This function is responsible for 
determining how much space is required, demographic and market analysis of 
locations, and owned versus leased funding strategies. 

Client Management. The system allows project initiation and 
funding approval by clients throughout the corporation via a desktop browser 



coupled to the system via a corporate intranet. This concept facilitates self- 
service delivery. The request component allows clients to specify requirements 
for construction, renovation, relocation or office furniture. 

Project Support. The system assists the real estate department staff 
in creating budgets and controlling how budgets are dispensed though purchase 
orders, work orders and contracts. This includes the table maintenance involved 
in vendor authorization, workload, reassignment of tasks, security access and 
security registration, and changes to processes. Project support is provided for 
the administrative processes such as administering roles and responsibilities, 
which includes signing authority. 

Project Management. The business objects of the system of the 
present invention assist a project manager in creating a project budget and 
controlling how that budget is dispensed through purchase orders, work orders 
and contracts. Invoices are processed against the commitments and are paid 
through an electronic accounts payable interface. The underlying system 
structure provides standardized work processes through processing templates. 
The system provides automated control and management of the process. This 
methodology is expandable because it is template based, thereby providing an 
environment for financial based project management. Additionally, Project 
Management includes phases of project initiation, predesign, schematic design, 
design development, construction documents, procurement, preconstruction, 
construction, and post construction. The system includes project management 
functionality to assist in: Tracking Project Milestones; Corporate Cost Center 
Allocations for identifying how project expenses should be charged; Messages 
which are generic correspondence; Meeting Announcements and Minutes; 
Creation and approval of commitments; Approval of invoices; Project Close 
Outs; Complete Punch Lists; Project Evaluations; and Departmental Statistics. 



Vendor Management. The system allows direct access via the 
Internet to provide extensive functionahty for managing approved vendors in 
relationship to specific projects. This functionality allows an approved vendor 
to author Bids, Requests for Quotes (RFQs), Invoices, Punch Lists, Lien Waivers 
and Messages. Other documents can be received and processed with more 
limited functionality. These documents include Request for Proposals, Contracts, 
Work/Purchase Orders, Change Orders, Payment Confirmations and Meeting 
notices. In addition, an in-box allows for timely communications of messages 
and documents. 

The present invention automates the creation, processing and 
approval cycles of numerous documents involved in project management. It 
allows project initiation and funding approval by clients throughout the 
corporation via a desktop browser coupled to a corporate Intranet. A software 
application embodying the present invention and its underlying technology are 
appropriate for a paper intensive area. It reduces the approval cycle of projects. 
It automates the creation, processing and approval cycle of documents by routing 
documents electronically for on-line approval. 

Other objects, features, and advantages of the present invention will 
be apparent to one skilled in the art from the following description of the 
invention with reference to the accompanying drawing. 

BRIEF DESCRIPTION OF THE DRAWING 

For the purposes of illustrating the present invention, there is shown 
in the drawings a form which is presently preferred, it being understood however, 
that the invention is not limited to the precise form shown by the drawing in 
which: 

Figure 1 is an illustration of the structure of the system of the 
present invention; 



Figure 2 depicts the process flow of the present invention; 

Figure 3 illustrates the tree structure organization of project 
management data; 

Figure 4 depicts a user interface input screen for inputting a 
Request for Assistance; 

Figure 5 shows an approval hierarchy structure according to the 
present invention; 

Figure 6 illustrates a budget template and an example budget; 

Figure 7 depicts an On-call commitment to a vendor; 

Figure 8 shows a Purchase Order commitment; 

Figure 9 illustrates the creation of a bid package; 

Figure 10 illustrates the bid opening processing; 

Figure 1 1 depicts the processing of bid responses jfrom vendors; 

Figure 12 shows the processing of a vendor invoice; 

Figure 13 illustrates a funding document generated by the system 
of the present invention; 

Figure 14 depicts the close out information available to a project 

manager; 

Figure 1 5 illustrates a close out ledger; and 
Figure 16 depicts a partial closeout. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

Figure 1 illustrates the system 100 of the present invention. The 
various parties to the project managed by the system 100 communicate via a 
corporate Local Area Network (LAN) 105, Connected to the LAN 105 are 
various servers 110-120 on which reside the applications and databases 
supporting the system 100, Server 115 contains the applications that enable the 
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clients to initiate and approve project requests and approve funding for such 
projects. Work flow server 110 contains the applications which enable the 
project staff to create and route project documents and manage information. In 
a preferred embodiment, the workplace server 1 1 0 is accessed through an icon on 
5 the staffs' work stations 120 which operates in a windows environment. The 
appUcations can be developed using C, Powerbuilder™, SQL, Cold Fusion™, or 
other similar software development languages and tools. 

Database server 120 provides access to database 122 that contains 
the various databases housing the details of all of the projects under management. 

10 In a preferred embodiment, the databases on server 1 10 are relational database 
such as is available from the Oracle™ corporation. Illustrated in Figure 1 is a 
work station 125, such as a personal computer (PC), laptop computer or other 
such workstations for use by project managers. Clients (employees of the 
corporation initiating projects) access system 100 through a corporate intranet 

15 130 and client work stations 135. Vendors access system 100 using a vendor 

workstation 140 connect to the corporate LAN 105 preferably through the 
Intemet 145 using a browser. The vendor workstation 140 uses a "thin" client 
technology meaning that the majority of the software for the vendor access 
resides on LAN 105 (servers 110, 115). The firewall 150 provides all of the 

2 0 requisite security such as password protection, authentication and encryption (if 

necessary). 

System 100 provides security functions based on roles, signing 
authority and access rights. Security access is defined through a Role-Business 
Object-Function relationship. In addition, the ability to perform a function on an 
2 5 object (e.g., a document to be approved) depends on the state of the object. For 
example, as further described below, if a document has been approved, that 
document can no longer be modified so as to protect the integrity of the approval. 
Database 122 contains various tables that support the security function and allow 
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definitions such as: Roles to Person table that identifies all the roles a person can 
perform; a Functions to Business Object table that identify all the functions and 
menu items available to a Business Object; a Tree- views to Role table that 
identifies all the treeviews (described below) available for a role; a Functions to 
Role table used to classify the functions and menu items as enabled or disabled 
for each business object within a role; a Function Exceptions table that overrides 
the classification for functions and menu items for each business object within a 
role identified at the person level (in other words, include or exclude a specific 
function in this business object for a person playing this role). A further table 
contains the state of all of the objects being managed by the system. A history 
of the revisions to an object (e.g., the changes in state during the approval process 
of a document) is maintained for auditing purposes. An object in the present 
invention can have multiple documents associated therewith. For example, if the 
object is a bid, some of the documents associated with the bid could be a hst of 
vendors (requiring approval) and a commitment (requiring its own separate 
approval). 

Figure 2 illustrates a overview of the project process managed by the 
present invention. The process begins with a client 1 60 determining that there is 
a need for the creation of a project. In the preferred embodiment the project is a 
construction project. The client 160 initiate the project by generating a Request 
for Assistance (RFA). The Request For Assistance is typically generated by the 
client 160 with the assistance of a project manager 170. The process of 
generating an RFA with the aid of a project manager 170 is an iterative one that 
involves preparation, negotiation, performance and acceptance. The RFA 
contains the nature and scope of the project, the funding available for and 
required by the project, and the schedule by which the project must be complete. 
Although the RFA can be communicated by telephone call or e-mail, in a 
preferred embodiment of the present invention, the RFA is generated by the cUent 
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1 60 using system 100. Specifically, the client uses its workstation 1 35 to connect 
to LAN 105 through the corporate intranet 130 (Figure 1). The applications on 
web server 115 prompt the cHent 1 60 for all of the necessary information required 
to complete the RFA 165. The data contained in the RFA 165 is stored in 
5 database 122 in separate files associated with the project. 

After the cHent 160 and the and project manager 170 have finaUzed the 
RFA, it goes through an approval process (described below) within the cHent 
management chain 1 62 . Once the RFA has been approved by cHent management 
162 is it automatically forwarded to facilities management 172 for approval and 

10 assignment of a project manager 170. Once the project manager 170 has been 

assigned and receives the approved RFA, the project manager 170 uses the RFA 
as a blueprint. As shown in loop 173, the project manager 170 can typically 
delegate portions of the project to other groups (e.g., design work and its 
management can be delegated to a design group within the organization). As will 

15 be further described below, the project manager 170 creates bid packages, 
purchase orders and or contracts 175 which are used to solicit the work fi-om 
vendors 1 80. Typically project managers 1 70 work with the various vendors 1 80 
in refining the nature and scope of the project. The project managers 170 receive 
proposals firom the vendors 180 who are bidding on the whole or pieces of the 

2 0 project under consideration. The communication between the project managers 
1 70 and the vendors can occur using the telephone or e-mail, but preferably the 
vendors 1 80 communicate with the project managers using their workstations 1 40 
through the Internet 145 and firewall 150. 

For larger projects, the result of the bidding and proposal process is a 

2 5 contract 175 which defines, in detail, the tasks to be preformed by the vendors 
180 in completing the projects. The specific tasks to be accomplished can be 
defined via a Purchase Order, a facilities agreement or a service agreement. 
Typically, contract 175 is a master contract which defines the general nature of 
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the project as well as the general nature of the relationship between the 
corporation and the vendors 180. Pursuant to the contract 175, the project 
manager 170 will generate specific commitments to vendors 180 to pay for 
specific tasks performed by the vendors 180. The contract 175 further provides 
5 for the ability of the project managers 170 to issue change orders to the vendors 
1 80 as the scope of the project changes during the evolution of the project. 

Upon completion of a task, the vendors 180 issue an invoice 185 
to the corporation. The invoice 1 85 can be transmitted to the corporation via 
tradition paper method, but preferably is transmitted in an electronic form 

1 0 compatible with system 1 00. If received in paper form, an invoice 1 85 is scanned 
so that it is rendered in electronic form which can be incorporated into system 
100 in database 122. The invoice 185 is reviewed by a project analyst 190 for 
comparison with the contract and the commitment to the vendor 1 80. The invoice 
185 then goes through an approval process by the project manager 1 95 according 

15 to the business rules for the project as further described below. Once approved, 
the payment on the invoice goes through an accounting process 200 in which the 
payment is validated and charged against the appropriate portions of the contract. 
The payment is then remitted 205 to the vendor either through a credit to the 
vendor's Demand Deposit Account (DDA), via check or via Electronic Data 

2 0 Interchange (EDI) remittance. 

Figure 2 has depicted the general process of how a project is initiated and 
managed. The remainder of the Figures will illustrate how system 100 facilitates 
the initiation management and closure of the project process. As previously 
described, the workstations for managing the project process (120, 125 in Figure 

2 5 1) operate in a windows environment although any other suitable network 

operating system (e.g., Unix) can be employed. System 100 includes security 
procedures, such as sign-on procedures, as known by those skilled in the art. 

00477003 I 
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Figure 3 illustrates a typical user interface screen 250 which will help explain the 
structure and functions of system 100. 

Information concerning projects managed by system 100 are preferably 
organized in folders 255 by projects. In a preferred embodiment, the folders 255 
5 are organized in a tree structure 260. User interface 250 illustrates one tree 
structure 260 of a particular project 270. System 1 00 contains various predefined 
tree views of folders 255 which are selected using list box 265. Specifically 
illustrated in Figure 3 is a tree view entitled "My Projects" in list box 265. The 
tree view of "My Projects" illustrated in Figure 3 is the standard default view of 

10 system 100, The "My Projects" tree view is most frequently used by project 

managers and other support staff Other tree views access information in a 
variety of ways. Other tree views include: a close out master view that lists all 
of the closed projects; a major expenditure plan view that lists all of the major 
projects; "my" major expenditure plan view which lists the major projects which 

15 a particular project manager is managing; a personal view that is an information 
folder for use by the user to store data for activities not related to specific 
projects; a projects by business sector view that lists all of the projects, sorted by 
major business division; a project by facilities division view that lists all projects 
sorted by a specific facilities department within the corporation; a view of 

2 0 projects by location that lists all of the projects sorted by location; a view of 
projects by project manager that lists all of the projects sorted by the project 
manager managing the project; a projects being supervised view that lists all of 
the projects being managed by the staff of a manager within the corporation; a 
view of recently approved documents that lists all of the documents that a user 

2 5 has approved within a predetermined period of time (e.g., two weeks); a view of 
system tables that lists various categories of system data such as roles, user 
profiles, and signing authorities; and a vendor view that lists all of the vendors 
sorted by several categories. Although the above is not an exhausted list of all of 

00477003 I 
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the views capable of creation in the system 100 of the present invention, it is a 
preferred list of the views. 

Each of the user interface screens of the system 100 include toolbars 275, 
280 containing icons that provide short cuts to the functionality of system 100, 
5 In a preferred embodiment, the icons on toolbar 275 are consistent across the user 
interface screens of system 100. These icons provide basic functionality to all 
screens such as a button for returning the user to default tree view, a print button 
which prints the screens, a close button which closes a screen in which the user 
is currently operating, a tile up button that returns the screen to the standard 

1 0 screen format with the tree view 260 on the left hand portion of the screen and the 
selected item on the right hand portion of the screen, and an exit button that is 
used to exit the system. 

The icons on toolbar 280 change fi:om screen to screen, depending on the 
function being performed by the user. Some of the toolbar 280 icons illustrated 

15 in Figure 3 include a new document icon 281 that produces a new document 

menu; a view notes button that produces a list of all notes created using the 
notebook feature of the present invention as further described below; a refresh 
button that renews and updates the tree view after completing an activity; a toggle 
tree button that toggles between the tree view and a full screen view of the 

2 0 selected item on the right hand portion of the screen; and a create note button that 

activates the notebook feature of the present invention. The icons on toolbars 
275, 280 and other functions of the present invention are accessed using a 
standard input device of the user's workstation such as a mouse. The mouse is 
used to click on a button to activate a specific function, to select an item and to 

2 5 drag and drop items of information. 

As previously described, information is preferably presented to the user 
in a tree view 260, The specific tree view illustrated in Figure 3 illustrates the 
folders 255 associated with the project 270, The user illustrated in Figure 3 only 

00477003.1 
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has a single project 270, otherwise the other projects associated with the user 
would be illustrated in the tree view area. 

Eleven folders 255 are shown as being associated with the project 270. 
The project directory folder 282 contains a listing of all of the project team 
5 members as well as the project vendors. The list is populated from database 122 
(Figure 1) as individuals or vendors are identified on the project. The Request 
For Assistance folder 284 contains the approved RFA form as described above. 
The budget and fiinding folder 286 contains all budget worksheets and funding 
documents. These documents include a preliminary funding document, a 

1 0 supplemental funding document and surrogate funding documents. Project task 
folder 288 contains the project tasks that are set up to assign portions of the 
approved budget to specific trades (e.g., plumbing) in preparation for creating 
commitments to vendors. Commitments by trade folder 290 lists all of the 
commitments that have been prepared for a project (including draft, unapproved 

1 5 and approved commitments) . The approved commitments folder 292 contains all 
of the approved commitments. The payments folder 294 contains all approved 
invoices from vendors for which payment has been made. The bid documents 
folder 296 contains all information related to bids and bid waivers. Each bid 
listed in this folder is assigned a unique number for accounting tracking purposes. 

2 0 Reports folder 298 contains a tracking report with respect to the project which 

lists all commitments and payments. This folder can also be used to store copies 
of other reports. Projects attachment folder 300 contains sub-folders for storing 
scan documents or electronic files of plans, specifications, correspondence, 
schedules and fumiture/fmishes information for example. The close out folder 

2 5 302 contains partial and final close out information with respect to the project. 

Again, the above list of folders 282-302 is not exhaustive and any folders can be 
created which suit the needs of the particular project being undertaken or the 
corporate system in which the system of the present invention operates. 

00477003 1 
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The right hand portion of screen 250 depicts the information associated 
with the folder selected on the left hand portion of the screen. In this particular 
example, the project 270 has been selected and accordingly, a profile 304 of the 
project is displayed on the right hand portion of screen 250. The project profile 
5 304 contains information related to the category of the project, the project 
number, the project name, the location of the project, the division for which the 
project is being conducted and the cost center associated with that division as 
well as the current phase of the project. The project profile further includes a 
brief project description 306 as well as an area 308 for the project status. 

1 0 Although not specifically illustrated in Figure 3, every document within 

system 100 has its own notebook in which is recorded comments, issues or status 
information associated with the project. The notebook feature can be activated 
at any time, such as while preparing a document, during the approval process, or 
even after final approval. Notes can be saved generally in three different 

15 categories. A first category is a comment which includes general notes for the 
facility staff A second category of notes is the status of the project which 
contains on going project status information. This status information from the 
notebook is displayed in the status area 308 in the project profile area. The final 
general category of notes contains specific notes to be published to other 

2 0 members of the team such as the clients. The published notes are available to the 
clients as previously described through the corporate intranet 130. 

As previously described, the project management process initiated by a 
Request for Assistance (RFA). Figure 4 illustrates an initial user interface screen 
350 for creating an RFA. The RFA is prepared either directly by a requestor or 

2 5 by a coordinator within the business unit requiring the project. There are 

generally two types of information required on an RFA, requestor information 
352 and information related to the project requested 354. The input screen 350 
allows the user to input all of the required information into an electronic RFA 

00477003.1 



-14- 

form. In a preferred embodiment, the electronic form is used for projects over a 
predetermined dollar amount (e.g., $10,000). If the project total is less than the 
predetermined amount, the user can e-mail the project and requestor information 
to the facihty staff The facihty staff can then prepare an internal RFA on behalf 
5 of the requestor so that the request can be inputted and managed within the 
system 100 of the present invention. 

Once the RFA has been completed, the user saves the document and clicks 
on a button (not shown) to send the RFA for approval. This action brings up a 
client hierarchy screen 360 illustrated in Figure 5. This screen represents one of 

10 the unique features of the present invention. On screen 360, the user is able to 
identify the proper personnel required to approve the RFA. In the specific 
example depicted in Figure 5, three separate approvals are required for the RFA. 
The first approval is a business unit manager 362, the second approval by a 
business unit controller 364 and the final approval by a business executive 366. 

15 Different rules are capable of being set in the database 122 of system 100 such 
that depending on the scope of the project (typically the total dollar amount) the 
number of approvals will change. For example, for larger projects (e.g., above 
$ 1 00,000) a business unit executive 3 66 will be required to approve the RFA. In 
area 368, the user is able to select the actual person who is fulfilling the role 

2 0 required for approval. The database of system 100 contains all of the relevant 
information with respect to each person in each business unit that can fulfill each 
role (e.g., name, e-mail address, title, etc.). The user can select the appropriate 
person from a drop down menu by selecting the down arrow on each box in area 
368. 

2 5 Once the appropriate people have been selected for the approval roles with 

respect to the RFA, the user clicks on the submit button 370. This action 
automatically forwards the electronic RFA to the person fulfilling the role of the 
first level of approval required for the RFA. A notice of the pending RFA 

00477003 1 
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requiring approval is added to the workflow list of pending tasks of the approver. 
This workflow list is accessed by the approver using button 375. When activated, 
this button provides a list of all of the documents requiring the persons' approval. 
The approver is then able to click on the notice which will bring up the actual 
5 electronic RFA document for review by the approver. After the review is 
complete, the reviewer is able to type any notes into a comment area of the RFA 
document and select one of several actions. If the approver approves the RFA, 
the electronic RFA is sent to the next individual in the approval hierarchy. 
System 100 enables electronic signatures as is well known to those skilled in the 

10 art. The approver can also retum the RFA for clarifications to the previous 
approver or to the requestor. Such an action should be accompanied by the 
approver including notes in the comment area which further define the 
clarifications required. The approver can also disapprove the RFA which sends 
the form directly back to the requestor or client coordinator. Again, if the RFA 

15 is disapproved, the approver should include notes in the comment area including 
reasons for the disapproval. Finally, the approver can discontinue the review of 
the RFA and come back to complete the review at a later time. In this action, the 
notice of the pending RFA will remain in the approver's work list. If the RFA is 
approved by the final approver in the client hierarchy, the form is automatically 

2 0 routed to a dispatcher in the project management staff At this point, the 
approved RFA is assigned a project number and a project manager. 

The automatic approval process of the present invention has several 
distinct advantages. First, the process is instantaneous. Once a document has 
been submitted for approval, notice of the receipt of the document for approval 

25 is immediately sent to the approver and the document is immediately available 
for review. This is in sharp contrast to the prior art method of approval in which 
documents typically were rerouted using interoffice mail. Apart from the delay 
associated with such a mail system, documents were often lost or misplaced. 

00477003 1 
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Tracking the status of approvals using the present invention is as simple as 
clicking on a button on the user's screen. The prior art required someone to 
conduct a series of phone calls, e-mails and personal visits to the approvers. 
Another advantage of the approval hierarchy of the present invention is that it 
recognized the corporate reality that people often change jobs, responsibilities, 
and locations. If such a change occurs, the database 122 of system 100 is easily 
modified to reflect the change. For example, if someone having the role of an 
approver is promoted and another person takes over the role, the database can be 
easily modified to replace the promoted person with the successor. Any 
subsequent approvals will then be automatically forwarded to the successor. 
Similarly, if someone having a role is on a temporary leave or absence, any task 
assigned to that person (e.g., approvals) can be easily and temporarily reassigned 
to a substitute person. 

Additional functionality provided to the clients of system 1 00 is the ability 
to view a list of RFAs for its business unit by clicking button 378. This button 
will bring up a window containing all of the RFAs of the business unit. The list 
will include the project name, the date prepared, the status of the RFA and the 
status of the funding of the project. In a similar manner, a client is able to view 
a list of all of the fimding documents by clicking on button 380. The funding list 
will display all of the funding documents for projects on which the user is 
involved. Once a list is displayed in the system 100 of the present invention, the 
user is able to view the actual documents associated with the item by selecting the 
particular item. 

After the approved RFA has been received by the project staff, one of the 
first tasks for the project staff is to create a budget and funding documents for the 
project. Figure 6 illustrates a user input screen 400 for creating budgets and 
funding documents. In a preferred embodiment, budgets are created using 
predefined templates. Area 402 allows the user to view a list of all of the budget 
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templates available within system 100. These templates can either be global 
(general formats available to all personnel) or private (i.e., templates that the user 
has personally created for his or her own use). Once a template is selected, the 
template is displayed in area 403 on the left hand portion of screen 400. In the 
5 preferred construction embodiment of the present invention, the templates contain 

three levels of project information, including individual trades (e.g., lighting 
fixtures), trade categories (e.g., electrical) and summary categories (e.g., 
construction, 404 in Figure 6). The templates in area 403 can be viewed in the 
standard view as illustrated in Figure 6, or a tree view as previously described, 

1 0 that shows summary categories in expandable folders. 

Once the template is displayed, the user is able to create the unique budget 
for the project in area 406 by dragging and dropping the items from the template 
area 403 into the budget area 406. For each item in the budget, the user is 
required to input the unit 408, quantity 41 0 and price 412. Once these items 408- 

15 412 have been input by the user, system 1 00 automatically calculates the cost of 
the item 414. Additionally, system 100 allocates the cost as a capital item 41 6 or 
an expense item 418. System 1 00 additionally calculates an allowed contingency 
amount 420 which can be set in the system as a percentage of the cost (e.g., 10% 
of the capital cost). The user is able to increase or decrease this contingency 

2 0 amount in area 422. 

If the creation of the budget document lasts longer than the user session, 
the user can save the budget as a worksheet and come back at a later time and 
complete the budget. Once the budget has been finalized, it is saved in a final 
form. The budget is then used to create a funding document that requires 

2 5 approval . The budget is a very complex and detailed document(s) that potentially 
includes hundreds of trades, capital items, expense items, etc. Rather than have 
the client and facilities management approve the very detailed budget, the system 
of the present invention generates a funding document for approval. An example 

00477003 1 



-18- 

of a funding document is depicted in Figure 13. The funding document of Figure 
13 was generated by a template accessing data from the database containing the 
budget. It is appreciated that any template can be used to generate any type or 
form of funding document desired. As seen in this Figure, the funding document 
summarizes the capital items for the project 700 as well as the expense items 705. 
These summaries 700, 705 provide the approvers with an overview of the total 
spending for the project without the complexity of the details of the entire budget. 
Further shown in Figure 13 are the names of the approvers of the funding 
document as well as the dates of the approval. The funding document indicates 
approval by both the facilities department 710 as well as the management of the 
business unit 715. 

As previously described with the approval process for an RFA, the project 
staff member submits the funding document for approval which is automatically 
forwarded to the facilities hierarchy for approval. Again, the first person in the 
facihties hierarchy receives a notice in his or her work hst regarding the fiinding 
document to be approved. The same automatic forwarding of approved 
documents is follows as described above with respect to an RFA. Again, if at any 
level of the approval process the reviewer denies approval or requests further 
clarification, the funding document is automatically returned to the previous 
approver with notes in the comments section providing reasons for the 
disapproval or the required clarification. Once the funding document has been 
approved by all levels of the facilities hierarchy, it is automatically forwarded to 
the client hierarchy for its approval. In a preferred embodiment, the cUent 
business unit has a similar level hierarchy for approvals, depending on the scope 
and size of the project. The same approval process is repeated within the client 
business unit including automatic forwarding of approved funding documents. 
Once the funding document has received final approval fi:om the client hierarchy, 
it is automatically forwarded to the assigned project manager who acknowledges 
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the approved funding document. The funds are now available for commitments 
and the process of managing the project begins. 

With the approved RFA and budget in place, the project manager is able 
to begin the actual project management. This process starts with the project 

5 manager generating commitments to vendors for various aspects of the projects. 
In the preferred construction embodiment of the present invention, the 
commitments include: architectural/engineering on calls; Purchase Orders; bids; 
bid waivers; contracts; change orders; and work orders. 
Architectural/engineering on-calls are commitments for on-call consultant 

1 0 services which typically result in the generation of a purchase order. A Purchase 
Order is a commitment for goods, materials, equipment or services, typically up 
to a predetermined dollar amount (e.g., $25,000). In the preferred embodiment, 
commitments over the predetermined amount (e.g., $25,000), require competitive 
bids. Again, these bids result in purchase orders for goods, materials and 

15 equipment or contracts for the provision of services. Alternatively, for 
commitments over the predetermined dollar amount, biding can be waived 
pursuant to a special bid waiver approval process. Work orders are commitments 
made against a master contract with a vendor for certain services of any dollar 
amount and for other trade services up to a predetermined amount (e.g., $ 10,000). 

2 0 Change orders are amendments to previously approved purchase orders or^ 
contracts, either increasing or decreasing the dollar amount. The change order 
results in a revised purchase order or a revised contract. 

The commitments are created against the previously approved funding and 
begin with the creation of a project task that assigns a portion of the approved 

2 5 budget to a specific trade. In order to create a project task for a commitment, the 
project manager selects the new document icon (281 in Figure 3) to create the 
task. Activation of this icon 281 displays a document selection menu which 
includes the various documents which the project manager is able to create. A 
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selection exists for each of the above-identified types of commitments (e.g., an 
on-call commitment). By selecting one of the items, the project manager is 
required to complete a description of the project task including the trade, the 
protocol for the commitment (e.g., source, bid, waived bid, negotiated, national 
5 contract), the type of commitment (e.g., purchase order, contract, work order) the 
tax status of the commitment (e.g., taxable, nontaxable) and a detailed description 
of the scope of work to perform pursuant to the commitment. 

The project manager is further required to complete a trade code details 
section. All of the trade codes that are contained within the approved budget are 

10 displayed (e.g., electrical). The project manager is able to drag and drop the 
appUcable trades firom the project budget to the trade code portion of the project 
task. The project manager then types in the dollar amount for each applicable 
trade for the commitment. Once the project manager has completed the above, 
the project manager saves the project task and is then able to generate the actual 

15 commitment. 

Figure 7 illustrates a complete commitment request 450 for an 
architectural/engineering on-call. In creating this commitment 450, the project 
manager was prompted to enter information related to the project 455, 
information related to the consultant (vendor) 460, the scope of the job and the 

2 0 square footage affected and the fees associated therewith 465, as well as a 
summary of the funding and financial commitments 470, both with respect to this 
particular commitments and the project in total. Many of the items found on this 
on-call commitment were obtained firom pull down menus (not shown) such as 
the consultant. Other items such as the cost center to be changed for work 

25 performed are provided by system 100 as a default once the project number is 
inputted by the project manager. Once the on-call commitment has been 
completed by the project manager, the project manager submits the commitment 
for approval to the project staff As previously described, the approval process 
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is automatic, with each level of approval being able to approve the document, 
disapprove the document or return the document for clarification. 

In addition to the electronic conmiitment, system 100 provides the project 
manager with the capability of scanning in additional documents that are 
5 associated with the commitment or creating any attachment such as spreadsheets, 
JPEG files, drawings. In the preferred embodiment, such attachments are created 
using Object Linking and Embedding (OLE) compliant software. Additional 
documents attached to a commitment may include proposals from the consultant 
or vendor. These attachments are available for review by the approvers at their 

10 work stations by selecting a view menu and selecting the attachments choice on 
the view menu (not shown). 

Once an on-call commitment request has received final approval, system 
100 automatically generates a purchase order number and notifies the project 
manager (electronically) of the purchase order number. A hard copy of the 

1 5 purchase order is issued by the project staff to the vendor. Preferably, the vendor 
is also able to obtain an electronic copy of the purchase order through the Internet 
interface previously described with respect to Figure 1 . The purchase order 
contains all of the basic information contained in the on-call commitment request 
as illustrated in Figure 7. In the preferred embodiment, when the vendor opens 

2 0 the electronic purchase order (or other document such as a contract or a change 
order), the vendor is presented with a set of appropriate functions. For example, 
for contracts, a command button will be provided to Agree to the terms or Not 
Agree with an opportunity to comment or create addendum. The Agree function 
invokes an electronic signature process. Some functionality may not be available 

25 based on the stage of a particular process. For example, invoices cannot be 
created until a work document has been accepted. 

In the preferred embodiment, records relating to a vendor remain available 
in system 100 for a period of at least one year following the job's completion. 
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Documents the vendor can author include Bids, RFQs, Invoices, Punch Lists, 
Lien Waivers and Messages. Documents the vendor can receive and process with 
limited functionality are Request for Proposals, Contracts, Work/Purchase 
Orders, Change Orders, Payment Confirmations and Meeting notices. In this 
5 preferred embodiment, the vendor is only allowed to view documents they 
authored or documents intended for them. The ability to delete documents are 
limited from a vendor's perspective and may only be allowed depending on the 
state of a document. This will provide for a document draft feature prior to 
posting to the workflow. 

10 The generation of a project task for purchase orders is the same as 

described above with respect to on-call commitments. Figure 8 illustrates a 
request for a purchase order commitment 475 generated by system 100 of the 
present invention. The project profile information 455 is the same as described 
above with respect to the on-call commitment. The commitment information 480 

15 includes the trade involved, the type of commitment (a purchase order in this 
example) and the protocol for the commitment. The vendor information 485 
describes the vendor to which the Purchase Order is to be issued. Again, this 
information can be input by the project manager using drag and drop methods 
previously described from a master list of vendors for the selected trade. The 

2 0 selection of vendors can either by from all of the vendors contained in the system 
or from vendors with which the corporation has a master contract. The cost 
associated with the purchase order is entered in area 490 and the summary of the 
financial commitments is again listed in area 470. As with the on-call 
commitment described above, the project manager is able to scan non-electronic 

2 5 documents into the system for attachment to the purchase order. Once the 
purchase order request has been saved, it can be submitted for approval and 
proceeds through the approval hierarchy as previously described. Upon final 
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approval, the purchase order is issued to the vendor with notification being made 
to the project manager electronically. 

A project task for a bid is again created as described above. Once the 
project task has been created, the project manager is then able to create a bid 
5 package 500 as illustrated in Figure 9. System 100 automatically assigns a bid 
number 502 to the bid package as well as assigning the bid status 504 of 
"initialization". As previously described, a bid is an object that can have many 
documents associated therewith. Each document can have a separate approval 
process as described above. There is not necessarily a one to one relationship 

1 0 between documents and the object with which they are associated. The trade 506 
is obtained by the system from the information provided by the project manager 
in the creation of the project task. The project manager then inputs the invitation 
and bid due dates 508 and 5 10 as required by the project. The contract type 512 
is selected by the project manager from a pull down menu (not shown). The 

15 project manager further inputs any special instruction in area 514. The bid 
package total 518 is automatically calculated by the system as the sum of the 
tasks 520. The tasks 520 are initially populated by system 100 from the entries 
input the project manager when creating the project task. The project manager 
can add additional tasks in area 520 that he or she desires to be bid upon. The 

2 0 task can relate to the same proj ect number or be associated with different proj ects , 
The price options 522 defaults to a base price, but the project manager can select 
altemative pricing options from a pull down menu (not shown). The documents 
supporting the bid are Usted in area 524 and include such documents as 
architectural or engineering drawings as well as equipment specifications. 

2 5 Once the bid package has been saved. The project manger is provided 

with a bid package vendor selection screen that allows the project manger to 
choose the vendors from which bids will be requested. Again, the project 
manager is able to select the vendors from a list complied from the database 122 
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in system 1 00. Once the project manager has finished selecting the vendors from 
which bids will be requested, the list is saved and submitted for automatic 
approval as described above. Once the list of proposed bidders has been 
approved, the bid package is sent to each of the bidders in hard copy form and 
5 preferably in electronic form. 

Prior to the bid due date, the bidders submit their bid proposals in response 
to the bid package. Due to legal concerns, it its preferable that the bids be opened 
and witnessed by two and preferably three witnesses. Figure 10 illustrates an 
input screen 550 used for conducting the bid opening. As illustrated in this 

10 Figure, three witnesses 552 are provided. System 100 requires these witnesses 
552 to input their IDs and passwords when conducting the bid opening. As each 
bid is open, the information from each vendor is input into area 554. The vendor 
name and the price options are defaulted by the system 100 from the approved 
proposed bidder list previously described. The amount 556 is obtained from the 

15 vendors bid and is input into the system by the project staff Additionally, the 
actual bid documents are scanned into system 1 00 and linked as attachment to the 
project. Once all of the bids from the selected bidders have been entered, the bid 
responses on screen 550 is saved and the bid opening is officially closed. The 
project manager is now able to perform an evaluation of the bids. 

2 0 In performing the bid evaluation, the project manager selects the bid 

documents folder (296 in Figure 3) to view the various bids. The bid documents 
folder contains all of the bids associated with the selected project. Selecting a 
modify button (not shown) activates a bid evaluation screen 560 as illustrated in 
Figure 1 1 . As seen in screen 560, each of the bidding vendors is displayed. The 

2 5 project manager is able to enter a qualified price 562 which is either the bid 
amount submitted by the vendor during the bidding process or an adjusted 
amount due to clarifications with the vendor after the bid has been opened. The 
project manager is additionally able to enter any comments on the pricing in area 
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564 with respect to each of the vendors. The project manger is then required to 
rank the vendors in area 566 and provide a reason for selecting a particular 
vendor in area 568. If addition documents have been submitted by the vendors, 
they can be scanned in and attached to the data for project as well as other 
5 attachment such as drawings. Once the project manager has completed his or her 
ranking 556, the bid evaluation is saved and submitted for approval. The 
automatic approval process proceeds as described above with respect to the 
approval hierarchy. 

The above has described a process for creating and approving three types 
10 of commitments, namely architecture/engineering on calls, purchase orders and 
bids. Similar processes are performed for the creation and approval of bid 
waivers, work orders and change orders. These processes shall not be specifically 
described herein, those skilled in the art appreciated how such processes are 
accomplished. 

15 After the commitments have been made to the various vendors and the 

work has been completed, the vendors submitted invoices for the services and 
materials provided pursuant to the commitments. In a preferred embodiment of 
the present invention, the invoices are electronically transmitted from a vendor 
workstation 140 (Figure 1) through the Internet 145 and the firewall 150 for 

2 0 receipt by system 1 00 . Alternatively, paper invoices may be submitted, scanned 
and the data entered into the system either manually or through drag and drop 
methods. The project manager reviews the invoice data contained in system 100 
against the scanned copy and makes any necessary adjustments in the payment 
amount, retainage, freight/dehvery or tax, based on the actual goods or services 

2 5 provided. 

Figure 12 illustrates an example of an invoice data entry screen 600. After 
an invoice has been received, the purchase order number 602, the invoice number 
604 and the invoice date 606 are entered. System 100, using the purchase order 
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number 602, automatically fills in the commitment information 608 as well as the 
vendor information 610. The amount of the invoice including the material 
amount, the freight amount and the taxable amount are entered in area 612. Once 
the data has been entered on invoice data entry screen 600, the data is saved and 
submitted for approval. The invoice approval process follows the approval 
hierarchy described above with respect to the other documents generated by the 
system. In a preferred embodiment, if the invoice amount does not exceed the 
commitment amount, the project manager alone can approve the invoice. If the 
invoice amount does exceed the commitment amount, the project manager can 
prepare a change order. The change order requires approval through the 
hierarchy and the issuance of a revised purchase order reflecting the adjusted 
commitment amount. Once the invoice has been approved, the payment can be 
made to the vendor either through the issuance as by check, crediting of the 
vendors demand deposit account, or through other EDI means. 

One further advantage of the present invention is the automatic nature of 
the tracking of the accounting information. A general rule is that any required 
accounting information (e.g., the business unit to which items will be charged) 
is captured by the system as soon as possible and thereafter carried through 
throughout the project. For example, once the client identifies the business unit 
to be charged, this identification is automatically carried into the templates for the 
project, commitments and invoices. All documents created from these templates 
will therefore automatically carry the identification of the business unit to be 
charged. 

As briefly described above, one of the features of the present invention is 
the ability to automate the close out process. The process of closing out a project 
has historically been an arduous and manually intensive process. As previously 
described, the preferred embodiment of the present invention relates to 
construction projects, and the close out process will be described in terms of this 
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embodiment. The closeout procedures of the present invention automate the 
financial transactions associated with the following two processes: handling of 
a project's CIP (construction-in-progress) account balance; and the final closing 
of a project. 

5 The CIP account is a holding account that captures a construction project's 

capital expenditures. At the end of the project, the balance in the CIP account is 
passed to a fixed asset (F/A) account for depreciation. Until the asset has been 
thus transferred, it cannot be depreciated. After the balance is passed to a fixed 
account it starts depreciating thus creating depreciation expenses for portion of 

1 0 the corporation that is benefitting fi"om the project. There is no hard requirement 
for the construction project to be 100% complete in order to commence 
depreciation. Depreciation can start with the payment of the first invoice with 
respect to the project. Typically, financial accounting rules governing 
construction projects employ an 80% threshold for commencing depreciation 

15 (i.e., 80% of the project must be complete before depreciation is started). The 
specifics of a project might require for the depreciation to be started both before 
or after an 80% threshold is reached. 

As previously described, many of the processes of the method and system 
of the present invention are driven by the documents related to the project. The 

2 0 final closing of a project in the system of the present invention is a system 
controlled procedure that starts with automatic examination of various states of 
the project documents. As a result of this thorough examination, the system 
produces an on-line diagnostics which highlights all inconsistencies detected by 
the process. The problems are categorized and displayed for the project manager. 

25 The system performs several types fimctions related to close outs, 

including a partial close out, a fiill close out, abort a close out and cancel a close 
out. A partial closeout is a type of closeout that is done when there is a need to 
move a portion of CIP balance to a F/A account. On larger projects, either in 
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tenns of funds and or the period of time for completing the entire project, having 
multiple partial closeouts is a very useful function practical. A full closeout is a 
type of closeout that is performed by the project manager only once. After 
successful completion of fall closeout the project is closed to any further activity 
5 (including commitments and payments) . A Cancel closeout is a type of closeout 

that is performed by the project manager in a case where a project was initiated 
in the system of the present invention but, before any commitments were issued 
to the vendors or any invoices were paid, the decision was made to stop it. An 
abort closeout is a type of closeout that is performed by a project manager when 

10 the client requested to stop the project after the funding was approved, 
commitments were issued and/or invoices were paid. 

A trigger built in the system initiates the first partial closeout for a project 
when the payment of a particular invoice meets the 80% threshold. The 80% 
threshold is with respect to the entire project. This trigger for a partial close out 

1 5 can be set to occur with respect to any event that is kept track of in the system. 

For example if there are several phases of a project, the trigger can cause a partial 
closeout at the completion of a particular phase. The trigger initiates a workflow 
process gets started that opens a closeout session. The system automatically links 
all of the paid invoices for the project to the closeout session created by the 

2 0 trigger. The system also generates a substantial number (sometimes hundreds) 
of financial transactions that will be sent to the General Ledger (G/L). 

The work flow process sends the generated transactions to an analyst in the 
financial area. After reviewing the transactions, the analyst approves the session. 
This single automated procedure alone replaces a substantial manual effort 

2 5 (document collection, data entry, data validation, etc.,) which would take weeks 
or even months to complete. The financial analyst can request that the system 
start a partial closeout if needed. In the preferred embodiment, there is no 
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system-imposed limit on the number of partial closeouts that can be processed by 
the system. 

Fig. 14 illustrates the close out information that the system makes 
available to the project manager. As previously described with respect to Fig. 3, 
5 the tree structure of folders in the proj ect manager' s directory includes a close out 
folder 800. Opening the close out folder brings up the screen 802 seen in the left 
hand portion of Fig. 14. Close out screen 802 contains six tabs 805-830 for 
viewing further information with respect to the status of the various close outs 
with respect to a project. 

10 As illustrated in screen 802 in Fig. 14, the Financial Summary tab 805 

displays a summary of the overall financial status of the project. Information in 
area 835 provides identification of the project, while the information in area 840 
summarized the actual financials. The financial information in area 840 includes 
the budget for the project, the amount of the budget that has been committed, the 

1 5 amount of the commitments that have been paid, the percentage of the budget that 

has been paid, the retainage held and the retainage paid. On this single summary 
screen 802, the project manager is quickly able to obtain a summary of the 
progress, from the financial point of view, of the project. 

Each of the other tabs, commitments 810, unapproved budget 815, 

2 0 unapproved commitments 820, change orders 825 and invoices 830 respectively 
bring up screen that detail the status of the subject matter related to the items 
associated with the tab. For example, the commitments tab 820 brings up a 
screen (not shown) that shows in detail all of the commitments that were created 
in the system. For each commitment, the screen shows the vendor to which the 

2 5 commitment has made, the category (e.g., construction, move) the amount of the 
commitment, the amount paid to date and the remaining balance of the 
commitment. The remainder of the tabs 8 1 0-830 bring up similar screens that list 
all of the items associated with the tab. 
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The folders Closeout Ledger 850 and Partial 860 in the project manager's 
tree directory contain further information related to the closeout status. The 
closeout ledger folder 850 bring up a screen 900 as illustrated in Fig. 15. This 
ledger screen 900 includes a summary are 905 and a detailed area 910. Within 
5 the detailed area 910, there is an entry for each of the closeouts associated with 

the project. In the particular example depicted in this Figure, only a single partial 
closeout has been executed with respect to the project. Fig. 16 illustrates the 
details associated with a partial closeout. Area 950 lists the project information 
and the project details are listed in area 955. Area 960 contains the details as to 

1 0 the G/L accounts to which the items in the partial closeout were assigned. Area 
970 details the different G/L accounts to which items were posted as well as the 
depreciation schedule that is assigned to the items. 

When a project has been completed, the project manager initiates a final 
closeout. Again, the full level of automation associated with the partial closeout 

15 as described above is applied to the full close out. In contrast to a partial closeout 
though, additional tests are performed to make sure that no unfinished business 
associated with the project is left unattended. For example, one test is performed 
to expose any unpaid invoices. Another test is performed to identify any 
commitment that is not fully paid. A further test is performed to identify any 

2 0 credit from a third party (e.g. a real estate) due to the project that is not collected. 
And so on. A full diagnostic of the state of the project is presented to the project 
manager in a manner of seconds and a list of actions required is fully identified. 
In the prior art manual process, this undertaking would have required days if not 
weeks to complete. 

25 To close projects that were canceled before they were started and those 

that were stopped after they were started, two other types of closeout processing 
are performed as previously described, Cancel closeouts and Abort closeouts. 
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Various tests are performed by the system to help the project manager to handle 
these exceptional conditions correctly. 

Although the present invention has been described in relation to particular 
embodiments thereof, many other variations and other uses will be apparent to 
5 those skilled in the art. It is preferred, therefore, that the present invention be 
limited not by the specific disclosure herein, but only by the appended claims. 
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WHAT IS CLAIMED IS : 

1. A method for automating the management of a project, the method 
comprising the steps of: 

generating at least one electronic document associated with the project; 
5 identifying entities that comprise an approval hierarchy; and 

automatically forwarding a notice requesting approval of the at least one 
electronic document to a successive one of the entities in the approval hierarchy 
upon approval of the at least one electronic document by a previous entity in the 
approval hierarchy. 

2. The method as recited in claim 1, the method further comprising the 
steps of: 

one of the entities in the approval process requesting clarification with 
respect to the at least one electronic document; and 
5 automatically forwarding the at least one electronic document to one of a 

previous entity in the approval hierarchy and the document originator for the 
requested clarification. 

3. The method as recited in claim 2, the method further comprising the 
steps of: 

opening an electronic notebook associated with the at least one electronic 
document; 

5 generating the requested clarification in the electronic notebook; and 

forwarding the at least one electronic document back to the entity that 
requested the clarification. 

4. The method as recited in claim 1, the method further comprising the 
steps of: 
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one of the entities in the approval process disapproving the at least one 
electronic document; and 

automatically forwarding the at least one electronic document to one of a 
previous entity in the approval hierarchy and the document originator. 

5. The method as recited in claim 1, the method further comprising the 
step of: 

determining if a monetary value associated with the at least one electronic 
document requires that at least one electronic document obtain the approval of a 
5 higher level entity in the approval hierarchy. 

6. The method as recited in claim 1, the method further comprising the 
step of temporarily substituting a substitute entity for one of the entities in the 
approval hierarchy. 

7. The method as recited in claim 1, further comprising the step of 
maintaining the at least one electronic document in a central storage location to 
which the entities in the approval hierarchy can access, review and approve the 
at least one electronic document. 

8. The method as recited in claim 1, wherein the at least one electronic 
document is a request for assistance that initiates the project. 

9. The method as recited in claim 1, wherein the at least one electronic 
document is a contract. 

10. The method as recited in claim 1, wherein the at least one electronic 
document is a commitment with respect to a vendor on the project. 
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1 1 . The method as recited in claim 1 , wherein the at least one electronic 
document is a bid. 

12. The method as recited in claim 1, wherein the at least one electronic 
document is a funding document that contains the funding for the project. 

13. The method as recited in claim 1, wherein the at least one electronic 
document is a purchase order. 

14. The method as recited in claim 1, wherein the at least one electronic 
document is a change order. 

15. The method as recited in claim 1, wherein the at least one electronic 
document is an invoice approval document. 

16. The method as recited in claim 1, further comprising the step of 
attaching a digital signature to the at least one electronic document in order to 
indicate the approval of an entity in the approval hierarchy. 

17. The method as recited in claim 1 , wherein the electronic document is 
generated by a client and wherein the approval hierarchy is a client approval 
hierarchy, the method further comprising the steps of: 

identifying project management entities that comprise a project 
management approval hierarchy; and 

automatically forwarding a notice requesting approval of the at least one 
electronic document to a successive one of the project management entities in the 
project management approval hierarchy upon approval of the at least one 
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electronic document by a previous project management entity in the project 
management approval hierarchy. 

18. The method as recited in claim 1, wherein there are a plurality of 
electronic documents, the method further comprising the steps of: 

organizing the plurality of electronic documents into folders; and 
providing a plurality of views of the plurality of electronic documents. 

19. The method as recited in claim 1, further comprising the steps of: 
establishing a user profile for each user participating in the method; and 
limiting a user's access to the at least one electronic document based on 

a parameter in the user profile. 

20. The method as recited in claim 1, further comprising the step of 
generating an electronic workflow list for a user that contains a list of electronic 
documents that require an action by the user. 

21. The method as recited in claim 1, wherein the step of automatically 
forwarding the notice further comprises forwarding the notice on an intranet. 

22. The method as recited in claim I, further comprising the steps of: 
generating a budget for the project; and 

generating a funding document using the budget, wherein the at least one 
electronic document is the funding document. 

23. The method as recited in claim 22, wherein the step of generating the 
budget further comprises the steps of: 
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selecting one of a plurality of pre-existing templates for the budget, the 
selected template containing a plurality of selectable budget items; and 
selecting at least one of the selectable budget items. 

24. The method as recited in claim 23, wherein the step of selecting the 
at least one of the selectable budget items further comprises the step of using a 
drag and drop method. 

25. The method as recited in claim 1, further comprising the step of 
attaching at least one other electronic file to the at least one electronic document. 

26. The method as recited in claim 25, wherein the at least one other 
electronic file is a second electronic document. 

27. The method as recited in claim 26, further comprising the step of 
generating the second electronic document from an original paper document. 

28. The method as recited in claim 25, wherein the at least one other 
electronic file is an image file. 

29. The method as recited in claim 25, wherein the at least one other 
electronic file is a spreadsheet file. 

30. The method as recited in claim 1, wherein there are a plurality of 
electronic documents associated with the project , and wherein at least a subset 
of the plurality of electronic documents are related to financial transactions, the 
method further comprising: 
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performing a closeout operation with respect to the electronic documents, 
wherein the closeout determines which, if any, of the electronic documents are 
related to incomplete financial transaction. 

3 1 . The method as recited in claim 30, wherein the project has not been 
completed, the step of performing the closeout further comprises performing a 
partial closeout, wherein the partial closeout closes out electronic documents 
related to completed financial transactions. 

32. The method as recited in claim 30, wherein the project has been 
completed, the step of performing the closeout further comprises performing a 
fiill closeout, wherein the full closeout closes out all electronic documents related 
to financial transactions. 

33 . The method as recited in claim 30, wherein the step of performing the 
closeout further comprises transferring a balance of a completed financial 
transaction to a General Ledger account. 

34. The method as recited in claim 30, wherein the step of performing the 
closeout is not performed until the project has been 80% completed. 

35. A method for automating the management of a project, the method 
comprising the steps of: 

generating at least one electronic document associated with the project; 
identifying entities that comprise an approval hierarchy; 
automatically forwarding a notice requesting approval of the at least one 
electronic document to a successive one of the entities in the approval hierarchy 
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upon approval of the at least one electronic document by a previous entity in the 
approval hierarchy; 

a first one of the entities in the approval process requesting clarification 
with respect to the at least one electronic document; 

automatically forwarding the at least one electronic document to one of a 
previous entity in the approval hierarchy and the document originator for the 
requested clarification; 

second one of the entities in the approval process disapproving the at least 
one electronic document; and 

automatically forwarding the at least one electronic document to one of the 
previous entity in the approval hierarchy and the document originator. 

36. A system for automating the management of a project, the system 
comprising: 

a network; 

a project manager workstation coupled to the network; 

at least one client workstation coupled to the network, wherein the at least 
one client workstation is used to identify entities that comprise an approval 
hierarchy; 

a database server coupled to the network, the database server containing 
at least one electronic document associated with the project; 

a workflow server coupled to the network wherein the workflow server 
automatically forwards a notice requesting approval of the at least one electronic 
document to a successive one of the entities in the approval hierarchy upon 
approval of the at least one electronic document by a previous entity in the 
approval hierarchy. 

37. The system as recited in claim 36, 
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wherein one of the entities in the approval process requesting clarification 
with respect to the at least one electronic document; and 

wherein the workflow server automatically forwards the at least one 
electronic document to one of a previous entity in the approval hierarchy and the 
5 document originator for the requested clarification. 

38. The system as recited in claim 37, the system further comprising: 
an electronic notebook associated with the at least one electronic 

document, wherein the requested clarification is generating in the electronic 
notebook, and wherein the at least one electronic document is forwarded back to 
5 the entity that requested the clarification, 

39. The system as recited in claim 36, 

wherein one of the entities in the approval process disapproves the at least 
one electronic document, and 

wherein the workflow server automatically forwards the at least one 
5 electronic document to one of a previous entity in the approval hierarchy and the 
document originator. 

40. The system as recited in claim 36, wherein the workflow server 
determines if a monetary value associated with the at least one electronic 
document stored in the database server requires that at least one electronic 
document obtain the approval of a higher level entity in the approval hierarchy. 

41. The system as recited in claim 36, wherein a substitute entity is 
temporarily substituted for one of the entities in the approval hierarchy. 

42. The system as recited in claim 36, the system further comprising: 
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a central storage location coupled to the database server, wherein the at 
least one electronic document is stored in the central storage location and wherein 
the entities in the approval hierarchy can access, review and approve the at least 
one electronic document through the database server, 

43. The system as recited in claim 36, wherein the at least one electronic 
document is a request for assistance that initiates the project. 

44. The system as recited in claim 36, wherein the at least one electronic 
document is a contract. 

45. The system as recited in claim 36, wherein the at least one electronic 
document is a commitment with respect to a vendor on the project. 

46. The system as recited in claim 36, wherein the at least one electronic 
document is a bid. 

47. The system as recited in claim 36, wherein the at least one electronic 
document is a funding document that contains the funding for the project. 

48. The system as recited in claim 36, wherein the at least one electronic 
document is a purchase order. 

49. The system as recited in claim 36, wherein the at least one electronic 
document is a change order. 

50. The system as recited in claim 36, wherein the at least one electronic 
document is an invoice approval document. 
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51 . The system as recited in claim 36, the system further comprising: 

a digital signature attached to the at least one electronic document in order 
to indicate the approval of an entity in the approval hierarchy. 

52. The system as recited in claim 36, wherein there are a plurality of 
electronic documents, the system further comprising: 

a plurality of folders in which the plurality of electronic documents are 
organized. 

53. The system as recited in claim 36, the system further comprising: 

a user profile for each user participating in the system, wherein a user's 
access to the at least one electronic document is limited based on a parameter in 
the user profile. 

54. The system as recited in claim 36, the system further comprising: 
an electronic workflow list maintained in the workflow server for a user, 

the workflow list containing a hst of electronic documents that require an action 
by the user. 

55. The system as recited in claim 36, wherein the notice forwarded on 
the network. 

56. The system as recited in claim 55, wherein the network is an intranet. 

57. The system as recited in claim 55, wherein the network is the Internet. 

57. The system as recited in claim 56, the system further comprising: 
a budget for the project stored on the database server; and 
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a funding document stored on the database server, wherein the funding 
document is generated using the budget, and wherein the at least one electronic 
document is the funding document. 

58. The system as recited in claim 57, the system further comprising: 

a plurality of pre-existing templates stored on the database server, the 
plurality of pre-existing templates being used for the generation of the budget, 
each of the pluraUty of pre-existing templates containing a plurality of selectable 
budget items, 

59. The system as recited in claim 36, the system further comprising at 
least one other electronic file attached to the at least one electronic document. 

60. The system as recited in claim 59, wherein the at least one other 
electronic file is a second electronic document. 

61. The system as recited in claim 60, wherein the second electronic 
document is generated from an original paper document. 

62. The system as recited in claim 60, wherein the at least one other 
electronic file is an image file. 

63. The system as recited in claim 60, wherein the at least one other 
electronic file is a spreadsheet file. 

64. The system as recited in claim 1, wherein there are a plurality of 
electronic documents associated with the project , and wherein at least a subset 
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of the plurality of electronic documents are related to financial transactions, the 
system further comprising: 

a general ledger account stored on the database server, the workflow server 
performing a closeout operation with respect to the electronic documents, 
wherein the closeout operation transfers completed financial transactions to the 
general ledger. 

65. The system as recited in claim 36, wherein the network is a corporate 
intranet, the system farther comprising: 

a firewall coupled to the corporate intranet and coupled to an extemal 
network; and 

a vendor workstation coupled to the corporate intranet through the extemal 
network and the firewall. 

66. The system as recited in claim 65 wherein the extemal network is the 
Internet. 
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ABSTRACT OF THE DISCLOSURE 



A system and method for providing project management tools to support 
construction, renovations, maintenance and other projects. The system automates 
the creation, processing and approval cycles of the numerous documents involved 
with each project. The system provides standardized work processes through 
processing templates. The system provides automated control and management 
of the process. The system allows project initiation and funding approval by 
clients throughout the corporation via a desktop browser coupled to a corporate 
Intranet. A software application embodying the present invention and its 
underlying technology are appropriate for a paper intensive area. It reduces the 
approval cycle of projects. It automates the creation, processing and approval 
cycle of documents by routing documents electronically for on-line approval. 
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As a below named inventor, I hereby declare that: my residence, post office address and citizenship are as stated below next to my name; that I verily 
believe that I am the original, first and sole inventor (if only one name is listed below) or a joint inventor (if plural inventors are named) of the subject 
matter which is claimed and for which a patent is sought on the invention entitled: 

SYSTEM AND METHOD FOR AUTOMATED FINANCTAL PROJECT MANAGEMENT 

the specification of which is attached hereto, unless the following box is checked: 

D was filed on as United States patent Apphcation Number or PCT International patent 

appHcation number and was amended on (if any). 

I hereby state that I have reviewed and understand the contents of the above identified specification, including the claims, as amended by any 
amendment referred to above. 

^ I acknowledge the duty to disclose all information known to be material to patentability m accordance with Title 37, Code of Federal Regulations, 

I hereby claim priority benefits under Title 35, United States Code §1 19 of any foreign application(s) for patent or inventor's certificate or United 
States provisional application(s) listed below and have also identified below any foreign application for patent or inventor's certificate having a filing 
date before that of the application on which priority is claimed: 

Prior Foreign or Provisional Apphcation(s) 



COUNTRY 



APPLICATION NUMBER 



DATE OF FILING 
(day, month, year) 



PRIORITY CLAIMED 
UNDER 35 U.S.C. 119 



United States 



60/163,506 



04 November 1999 



YES X NO 



YES 



NO 



YES 



NO 



I hereby claim the benefit under Title 35, United States Code, §120 of any United States application(s) hsted below and, insofar as the subject matter 
of each of the claims of this application is not disclosed in the prior United States application in the manner provided by the first paragraph of Title 35, 
United States Code, §1 12, 1 acknowledge the duty to disclose information which is material to patentability as defined m Title 37^Coae of Federal 
Regulations, §1 .56 which became available between the filing date of the prior application and the national or PCT intemational filing date of this 
application. 



UNITED STATES 
APPLICATION NUMBER 



DATE OF FILING 
(day, month, year) 



STATUS 
(patented, pending, abandoned) 



I hereby appoint customer no. 2352 OSTROLENK, FABER, GERB & SOFFEN, LLP, and the members of the firm, Samuel H. Werner - Reg. No. 
18,510; Jerome M. Berliner - Reg. No. 18,653; Robert C. Faber - Reg. No. 24,322; Edward A. Meilman - Reg, No. 24,735; Stanley H. Lieberstein - Reg. 
No. 22,400; Steven I. Weisburd - Reg. No. 27,409; Max Moskowitz - Reg. No. 30,576: Stephen A. Soffen - Reg. No. 31,063; James A. Finder - Reg. 
No. 30,173; William O. Gray, III - Reg. No. 30,944; Louis C. Dujmich - Reg. No. 30,625 and Douglas A. Miro - Reg. No. 31,643, as attorneys with full 
power of substitution and revocation to prosecute this application, to transact all business in the Patent & Trademark Office connected therewith and to 
receive all correspondence. 

SEND CORRESPONDENCE TO: OSTROLENK, FABER, GERB & SOFFEN, LLP DIRECT TELEPHONE CALLS TO" 
1 180 AVENUE OF THE AMERICAS (212) 382-0700 

NEW YORK, NEW YORK 10036-8403 
CUSTOMER NO. 2352 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and belief are believed to 
be true; and further that these statements were made with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or botii, under Section 1001 of Title 18 of the United States Code, and that such willful false statements may jeopardize the validity of 
the apphcation or any patent issued thereon. 



FULL NAME OF SOLE OR FIRST INVENTOR 

Joseph Gendler 


INVENTOR'S signature/ / /^y. 


DATE / . 


RESIDENCE (City and either State or Foreign Country) /^^ 'f 

Fairlawn, New Jersey 


COUNTRY OF CITIZENSHIP 

United States 


POST OFFICE ADDRESS 

16-20 Radburn Road, Fairlawn, New Jersey 07/410 h ^ 


FULL NAME OF SECOND JOINT INVENTOR (IF ANY) 


INVENTOR'S SIGNATURE 


DATE 


RESIDENCE (City and either State or Foreign Country) 


COUNTRY OF CITIZENSHIP 


POST OFFICE ADDRESS 


FULL NAME OF THIRD JOINT INVENTOR (IF any) 


INVENTOR'S SIGNATURE 


DATE 


RESIDENCE (City and either State or Foreign Country) 


COUNTRY OF CITIZENSHIP 


POST OFFICE ADDRESS 



□ 
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